Designers/developers of integrated circuits variously referred to as ASIC's (Application Specific Integrated Circuits) or SoC's (System on a Chip) are faced with a problem. The current technology for design and development can handle either complexity or scale but not both. There are also further problems in developing product for enlarged markets.
SoC's are designed to meet the needs of specific applications or a range of specific applications. They have advantages over general purpose processors used for those applications. The advantages generally involve cost, size, power consumption and processing suited to the application. In some cases SoC's are the only way to fully meet application requirements.
In many cases, an SoC has been developed as the least common multiple of IPs in order to cover as many applications as possible. That has been considered as the solution for shorter time to market and less development cost. For example, an SoC with SATA, Ethernet, and PCIe can be developed for multiple applications, such as Network Attached Storage (NAS) or wireless router. Although PCIe will be disabled for NAS and SATA will be disabled for router, the time to market is shorter than developing two different SoC's.
With current technology, SoC's are relatively easy to develop if they have a relatively small numbers of cores or if the core interfaces are simple, all conform to the same set of standards and come from the same vendor (developer). Unfortunately, the market has driven SoC's to integrate large numbers of cores with complex interfaces that follow, to one extent or another, a number of different standards and come from a wide variety of vendors. Similar challenges exist in the context of multi-component (core, device, etc.) systems that are not fully integrated onto a single SoC or ASIC.
Although, there are some tools to help developers, the job of configuring individual cores, devices, and/or components in such a way that they can optimally work together to create an integrated system typically is largely manual. Configuring all the cores, devices, and/or components comprising a system for the best possible performance to accomplish the objective is referred to herein as “orchestration”.
Furthermore, the orchestration of a particular system may be focused on a single application. For example, even if 90% of the cores comprising an SoC could be used for another related application, that SoC has to be a separate semiconductor with separate orchestration. This raises the cost of both SoC's because it reduces the potential economy of scale. Optimal leveraging of economies of scale is what can make semiconductors so cost effective.
Another consideration is that the orchestration is required to manage optimization across multiple perspectives, such as performance, power, thermal, and so on. The existing development methods typically handle single perspective optimization per SoC. For example, an SoC for server application may be tuned for performance, and an SoC for consumer application may be tuned for longer battery life. However, these perspectives are no longer independent where complexity and scale converges.
Another consideration is that as the semiconductor industry moves from the 20 to 30 cores in a System on Chip/Package/Node to 300 and then 3,000 and beyond, the conventional bus interconnect architecture will no longer be economically nor technically feasible. As scale increases, the bus, in bus architectures becomes a gating item, i.e., a bottleneck. As the number of components communicating on the bus increases, the time required to enable and disable each component's access to the bus creates a limit condition. This limit condition is further squeezed by the finite bandwidth of the bus in the face of the amount of data that each component needs to communicate with its concomitant latency requirements.
At the same time, existing software drivers for cores will be based on the assumption of a bus architecture. The result is likely to be a two-step evolutionary process, where hardware architectures will start to evolve faster than the evolution of software modules creating intermediate solutions. Then, as software module evolution catches up, hardware architectures will move the rest of the way in their evolution.
FIG. 1 is a block diagram illustrating an embodiment of a wireless router system built using IP cores. In the example shown, an available set of IP cores 100 includes a Gigabit Ethernet core 102, a USB2/USB3 core 104, a video/graphics controller core 106, an application processor core 108, a SATA controller core 110, and a WiFi radio core 112. Through a design process 114 the cores 102, 104, 108, and 112 are selected, configured, and inter-connected to provide and implement an integrated circuit design 120 for a wireless router. The cores 106 and 110 are not used in the design, in this example because their functionality is not required to be included in the wireless router to be built using design 120. Typically, the design process 114 is labor intensive and time consuming. Mutually compatible cores having desired features and performance characteristics must be identified from a variety of sources, each potentially using a different way to describe its various IP cores. Once cores have been selected, their respective configurations must be determined based on their respective attributes, and an integrated design incorporating the selected and configured cores generated, for example by one or more human operators using design tools that partly automate the process.
FIG. 2 is a block diagram illustrating an embodiment of a system built using IP cores. In the example shown, the system 200 has been built by connecting the cores 102, 104, 106, 108, 110, and 112 of FIG. 1 via a high speed interconnect 202. Each of the cores 102, 104, 106, 110, and 112 has an associated range of supported and/or required data rates as indicated in FIG. 2. In a typical prior art design process, a human designer must consider the respective supported and/or required rates and must select a design rate and/or other configuration data for the respective IP cores. In addition, different applications that might be run on application processor core 108 may require and/or imply different peak data rates, such that the application(s) to be supported by the system may have to be taken into consideration in selecting the other cores, the required (or available) capacity of the interconnect 202, and the respective rates at which the IP cores will be configured to operate. The frequency at which the application processor and/or other cores will operate may also have to be determined and set.